This PR enables the nullFriendlyParameters feature in Java SDK generation, significantly simplifying how SDK end users provide optional and nullable values.

💡 What’s Changing
Prior to this change, end users had to wrap values explicitly:

.setMyParameter(Optional.empty());
.setAnotherParameter(JsonNullable.of(null));

With this feature enabled, users can now pass null directly:

.setMyParameter(null);
.setAnotherParameter(null);

This improves:

Developer experience – Cleaner, more idiomatic Java usage.

IDE feedback – JetBrains users get nullability hints via jakarta @Nullable / @NonNull annotations.

API cleanliness – Wrapper types like JsonNullable are handled internally and no longer leak into user code.

⚠️ Breaking Change — Rollout Considerations
This introduces breaking changes to method signatures and generated types. Any SDKs regenerating with this flag enabled will break compatibility for existing consumers.

As such:

This change must be released behind a version bump (typically a major version).

🤔 PATCH Semantics and Null Handling
A common concern with this change is how null values behave in PATCH-like operations, where setting a field to null often carries different intent than omitting it entirely.

To clarify:

✅ Nullable fields → passing null results in an explicit null being sent.

✅ Optional fields → passing null causes the field to be omitted from the request.

✅ Nullable + Optional fields → passing null results in null being sent; to omit, simply avoid calling the setter.

The generated SDK code handles this distinction under the hood, by converting values internally to the appropriate JsonNullable or JsonUndefined types - so users don’t have to manage those concerns themselves.